Load external data without copying it onto the JS heap - #1747

Loading a model from Cache Storage currently materialises every external-data file into the JS heap
before onnxruntime-web ever sees it: `loadResourceFile` reads the `Response` into a `Uint8Array`, and
`getModelDataFiles` passes that buffer on. For a multi-gigabyte model that is a full second copy of
the weights, live at the same moment the runtime is allocating its own.

A Cache Storage `Response.blob()` is a file reference rather than a copy, and onnxruntime-web accepts
one for external data as of the runtime bumped in the previous commit. So on a cache hit the bytes
can go straight from disk to the runtime and never enter the heap at all.

Measured on a 2.887 GB model, same runtime and same session: peak resident goes from 6,056 MB to
4,221 MB. The saving is the size of the weights, so it grows with the model.

Two deliberate limits.

It only applies on a cache HIT. Reading the stream to report download progress would defeat the
purpose — the chunks would be resident twice, once as buffers and once in Blob storage — and while
several gigabytes are arriving, progress is worth more than peak memory. Every load after the first
takes the new path, which is where the peak actually matters, and is unchanged for Node, which keeps
returning a path.

And it is opt-in, threaded from the one caller that knows it is looking at external data.
`loadResourceFile` is generic — it also serves config.json and tokenizer.json, whose callers parse
the result as text — so returning a Blob unconditionally would break them.

…ing it

The previous commit made a WARM load cheap: a cached file comes back as a Blob and its bytes never
reach the JS heap. A cold one was untouched, and a cold one is the case that fails.

`getModelDataFiles` starts every external-data chunk concurrently, and each is read into a
`Uint8Array` so download progress can be reported — so a first load peaks at the SUM of the chunks
rather than the largest. Measured on a 17 GB model from an empty cache: `Array buffer allocation
failed` at 16.2 of 17.0 GB, 13 GB cached, load failed. It succeeds on a later attempt only because
each file is cached as it completes, so the retry has less left to buffer.

The body can go straight into Cache Storage instead. `cache.put` takes a `Response` and writes it to
disk without materialising it, and reading it back with `cache.match` gives the same Blob a warm load
gets — so the bytes travel network -> disk -> runtime and never sit on the heap.

Progress survives, which is the only reason the buffer existed: a pass-through `TransformStream`
counts bytes as they go past. It holds one chunk, not the file, and backpressure keeps it that way.

If the cache refuses the write — QuotaExceededError being the expected one — it falls back to the
buffered path. That has to re-fetch rather than reuse the response, whose body the failed attempt
consumed.

`as_blob` changes the RESOLVED TYPE of `getModelFile`, not just how the
bytes are fetched, so two callers asking for the same file with different
values are not asking the same question.  Left out of the key, whichever
one arrives first decides for both and the other receives a `Blob` where
it expects a `Uint8Array`, or the reverse — silently, and only under
concurrency.  `return_path` is in the key already for exactly this reason.

Adds focused warm/cold tests against an in-memory cache and a stubbed
`env.fetch`, so they assert which branch ran rather than wall-clock
behaviour and touch no network:

  · cold — streams into the cache, resolves a Blob, stores exactly once
    (not a second time by the block at the end of loadResourceFile), and
    still reports progress up to the total, which is the reason the
    buffer existed;
  · warm — resolves a Blob from the cache without re-fetching, and
    reports the single completed event;
  · a cache that refuses the write falls back to a buffer and re-fetches,
    rather than failing the load;
  · `as_blob` unset still resolves a Uint8Array;
  · both orderings of a concurrent Blob/bytes pair get the type they
    asked for.

The last two fail without the key change and pass with it — checked by
reverting it.

The review is right that the claim and the default path do not match, and
the reason is that this PR has TWO savings which the comments ran
together:

  · The DOWNLOAD no longer buffers.  Streaming the body into Cache Storage
    and reading it back means the file never sits on the JS heap on its
    way in.  This happens before onnxruntime-web sees anything and holds
    whichever build is in use.  It is the half that stops a cold load of a
    model with several multi-gigabyte chunks dying in getModelDataFiles,
    where every chunk starts concurrently and the peak is their sum.
  · The SESSION may or may not copy.  Handing the runtime a Blob only
    avoids materialising it if the runtime can read it that way: the JSPI
    build can, the default asyncify build cannot.

So "the bytes never sit on the JS heap at all" was true of the download
and overstated end to end.  The comments now say which is which, and say
plainly that on the default build this buys the download and not the
session.

No behaviour change — comments only.

`pnpm build` runs `tsc --build`, and it has been failing on this branch
since the Blob was introduced — five errors, unnoticed because CI never
got past `pnpm install`.  Fixing the lockfile in the first commit would
have moved the red from install to build rather than clearing it.

  · `buffer` was annotated `Uint8Array` and now legitimately holds a Blob
    on both `as_blob` branches.  Widened rather than cast away at each
    use, so a future branch that forgets which it is fails at build.
  · `cache.match` is typed for every backend including the Node file
    cache; only a `Response` has `.blob()`, and only a `Response` reaches
    that line.  Cast instead of the blanket `any` it had.
  · `INFLIGHT_LOADS` holds Blob-resolving promises now.
  · `getCoreModelFile` never passes `as_blob`, so a Blob cannot come back;
    narrowed there rather than widening every caller of a function that
    only ever wants bytes or a path.
  · The store-at-the-end block cannot see a Blob either — a warm read is a
    cache hit, which never sets `toCacheResponse`, and a cold stream
    writes the entry itself and then clears the flag.  The narrowing says
    so, so a third branch that produced a Blob without storing it would
    land there loudly.

tsc --build is clean, the bundles build, and tests/utils is 296 passing.